1. Field of Invention
The invention relates to a workflow defining and managing system and, in particular, to a workflow defining and managing system that is capable of establishing flowcharts to control the progress of work or data.
2. Related Art
To improve the work efficiency and to integrate the operation procedures of different departments, one usually designs a workflow to link up all operation procedures in view of actual needs. Then, a flowchart is established for different departments, so that they can execute and control their operation procedures according to this flowchart.
A conventional flowchart for debug operation procedure will be described below with reference to FIG. 1A. As shown in FIG. 1A, a debug report generating department firstly collects bug-related data and forwards them to the manager of a debug department (step S01). In this step, for example, bug-related data could come from the customer service department or the test department, and the bug-related data is then forwarded to the debug report generating department. The debug report generating department then generates a debug request form, and forwards this debug request form to the manager of the debug department along with the bug-related data.
Then, in step S02, the manager of the debug department decides whether to accept this debug request form depending on whether the bug-related data is sufficient. If the manager accepts the debug request form, then jump to step S04. If the manager does not accept the debug report, then jump to step S03.
In step S03, when the manager of the debug department does not accept the debug request form, a rejecting message is returned to the debug report generating department, so that the debug report generating departing can gather the bug-related data again, and forward more sufficient data to the manager of the debug department.
In step S04, when the manager of the debug department accepts the debug request form, the manager forwards the accepted debug request form and the bug-related data to a debug engineer. Then, in step S05, the debug engineer begins the debug operation according to the debug request form and the bug-related data. To this point, the workflow for the whole debug operation procedure is finished. It should be noted that the above-mentioned workflow can be realized by conventional paper documents, or be realized by electronic forms using computers and network systems.
The above-mentioned workflow, however, is not suitable for many reasons when being implemented practically. For example, the debug engineer cannot report to the manager when the debug request form is wrong or when the bug-related data is insufficient. This results in that the debug operation procedure could not be finished smoothly. In addition, when the debug engineer finishes the debug operation procedure, the correctness of the debug operation cannot be confirmed effectively.
Besides, since each step of the workflow shown in FIG. 1A is designed sequentially according to the original request form, one must design another workflow and flowchart all over again when the original workflow is not suitable for practical use. FIG. 1B is an example of the flowchart of a new workflow, which comprises some extra steps. As shown in FIG. 1B, after the manager of the debug department forwarded the debug request form and the bug-related data to the debug engineer (S04), step S06 is performed. In step S06, the debug engineer determines whether to accept the debug request form depending on whether the bug-related data is sufficient. When the debug engineer determines that the bug-related data is insufficient, the workflow jumps back to step S02 so that he/she can return the debug request form to the manager. The manager then can re-confirm whether the bug-related data is sufficient. In addition, when the debug engineer confirms that the bug-related data is sufficient, then the workflow jumps to step S05 to proceed with the debug operation procedure.
Finally, in step S07, the manager of the debug department confirms the completion of the debug operation procedure. The whole debug workflow ends when the manager made a confirmation for the completion of the debug operation procedure. If the manager of the debug department has doubts about the result of the debug operation procedure, the workflow jumps back to step SOI to re-confirm the contents of the bug-related data and to run the whole debug workflow all over again.
As mentioned above, conventional workflow managing method is constituted by a plurality of workflow paths 21 and work stages 22 as shown in FIG. 2. Therefore, when revising the workflow, one must both adjust (e.g. add or delete) the workflow paths 21 and adjust (e.g. add, delete, or modify) relevant work stages 22. For example, steps S05 to S07 are added or deleted step-by-step, and the step order of the workflow is rearrange between these steps. The actions required are difficult and complicated. Furthermore, after the workflow being revised, since the procedures are different, old data often becomes incompatible with new workflow, which results in the missing of the old data when one must start the new workflow and abandon the old one in the middle of the debug operation procedure.
Therefore, it is a subjective to provide a workflow defining and managing system that is capable of establishing flowcharts to control the progress of work or data more effectively and to revise the procedures and integrate all data more easily.